Providing secondary coverage in a mobile communication system

ABSTRACT

Example methods, apparatus, articles of manufacture and systems for providing secondary coverage in a mobile communication system are disclosed. Example methods for a first device to provide secondary coverage in a mobile communication system include transmitting a secondary coverage signal and receiving a presence indication from a second device. Such example methods can also include reporting the presence indication to an access node of the mobile communication system. Such example methods can further include receiving information from the access node to enable relay node functionality in the first device in response to reporting the presence indication to the access node.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of and claims the benefit ofpriority to U.S. patent application Ser. No. 16/113,641, filed on Aug.27, 2018, which claims priority to U.S. patent application Ser. No.15/389,792, filed on Dec. 23, 2016, which claims priority to U.S. patentapplication Ser. No. 13/969,192, filed on Aug. 16, 2013, and eachapplication is hereby incorporated by reference in its entirety.

FIELD OF THE DISCLOSURE

This disclosure relates generally to mobile communication systems and,more particularly, to providing secondary coverage in a mobilecommunication system.

BACKGROUND

Mobile communication systems provide wide spread network coverage inmany parts of the world today, and the geographical regions in whichuser equipment (UE), such as mobile devices, can receive networkcoverage from access nodes, such as base stations, continues toincrease. Such network coverage is referred to herein as primarycoverage. However, there are and will continue to be scenarios in whicha UE cannot obtain network coverage from any network access node, suchas in remote geographic regions, or when network equipment fails due toa natural disaster. Secondary coverage techniques can extend thecoverage area of existing (and functional) access nodes by allowing UEsthat are not in the coverage area of any network access node to gainaccess to a network via UEs that are in the coverage area of one or morenetwork access nodes. For example, the Third Generation PartnershipProject (3GPP) long term evolution (LTE) standard specifies a secondarycoverage technique in which in-coverage UEs can implement relay nodefunctionality to provide network coverage for UEs that are not in thecoverage area of any network access node.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example mobile communication systemcapable of providing secondary coverage as disclosed herein.

FIG. 2 is a block diagram of an example secondary coverage processorthat can be used to implement one or more of the example UEs included inthe example system of FIG. 1.

FIG. 3 illustrates an example downlink LTE subframe supported by theexample system of FIG. 1.

FIG. 4 illustrates an example LTE downlink resource grid supported bythe example system of FIG. 1.

FIG. 5 is a block diagram illustrating an example secondary coveragescenario that can be supported by the example system of FIG. 1.

FIG. 6 is a block diagram illustrating a first example secondarycoverage solution in which in-coverage UEs are speculatively orstatically configured to enable relay node functionality.

FIG. 7 is a message sequence diagram illustrating a second examplesecondary coverage solution in which in-coverage UEs are configured toenable relay node functionality based on detection of not-in-coverageUEs operating in the example system of FIG. 1.

FIG. 8 is a block diagram illustrating transmission of secondarycoverage signals by in-coverage UEs to implement the second examplesecondary coverage solution.

FIG. 9 is a block diagram illustrating transmission of presenceindicators by not-in-coverage UEs to implement the second examplesecondary coverage solution.

FIG. 10 is a block diagram illustrating configuration of relay nodefunctionality by selected in-coverage UEs to implement the secondexample secondary coverage solution.

FIG. 11 is a block diagram illustrating not-in-coverage UEs obtainingnetwork access from the selected in-coverage UEs in accordance with thesecond example secondary coverage solution.

FIG. 12 is a timing diagram illustrating example timing relationshipsbetween example secondary coverage signals and associated examplepresence indicators conveyed in accordance with the second examplesecondary coverage solution.

FIG. 13 is a flowchart representative of an example process that may beperformed by the example secondary coverage processor of FIG. 2 toimplement secondary coverage processing for example in-coverage UE(s) inthe example system of FIG. 1.

FIG. 14 is a flowchart representative of an example process that may beperformed by the example secondary coverage processor of FIG. 2 toimplement secondary coverage processing for example not-in-coverageUE(s) in the example system of FIG. 1.

FIG. 15 is a flowchart representative of an example process that may beperformed to implement secondary coverage processing for example accessnode(s) in the example system of FIG. 1.

FIG. 16 is a block diagram of an example processor platform that mayexecute example machine readable instructions used to implement some orall of the processes of FIGS. 13-15 to implement the example system ofFIG. 1.

Wherever possible, the same reference numbers will be used throughoutthe drawing(s) and accompanying written description to refer to the sameor like parts, elements, etc.

DETAILED DESCRIPTION

Example methods, apparatus, articles of manufacture and systems forproviding secondary coverage in a mobile communication system aredisclosed. Example methods disclosed herein include methods for a firstdevice to communicate with a second device in a mobile communicationsystem. Such communication can include, but is not limited to, (1)exchanges of signal(s) from the first device, which may or may not bereceived by the second device, indicating the presence of the firstdevice, the ability of the first device to provide secondary coverage inthe mobile communication system, and/or an opportunity for the seconddevice to transmit signal(s) for receipt by the first device. (2)exchanges of signal(s) from the second device, which may or may not bereceived by the first device, indicating the presence of the seconddevice and/or a request from the second device for secondary coverage inthe mobile communication system, etc., and/or any other type ofcommunication exchange. For example, such methods can include the firstdevice transmitting a first signal indicating an opportunity for thesecond device to transmit a second signal. In such examples, the firstdevice has primary coverage from a first access node of the mobilecommunication system, whereas the second device does not have primarycoverage from any access node of the mobile communication system. Suchexample methods can further include the first device receiving a secondsignal from the second device.

Some such example methods can also include relaying information betweenthe second device and the first access node in response to receiving thesecond signal. Moreover, the information can be first information, andsome such example methods can further comprising receiving secondinformation from the first access node to enable relay nodefunctionality in the first device. In some such examples, the secondinformation received from the first access node causes the first deviceto stop transmitting the first signal and to start broadcasting asynchronization signal and system information to provide secondarycoverage to the second device. Additionally or alternatively, some suchexample methods can include reporting a presence of the second device tothe first access node, such that the second information is receivedafter the reporting of the presence of the second device to the firstaccess node

In some such example methods, the first signal is a secondary coveragesignal indicating that the first device is able to provide secondarycoverage in the mobile communication system. For example, the mobilecommunication system can support long term evolution (LTE)functionality, and the secondary coverage signal can include a referencesignal transmitted in a center number of resource blocks of an uplinksubframe. In some such examples, the center number is six (6), and thereference signal transmits a length-62 Zadoff-Chu sequence. Additionallyor alternatively, in some such examples, the secondary coverage signalis a first secondary coverage signal indicating that the first device isable to provide secondary coverage in the mobile communication system,and the example methods further include transmitting a second secondarycoverage signal that is to indicate timing associated with when thefirst device expects to receive the second signal.

Additionally or alternatively, in some such example methods, the secondsignal includes a presence indication that indicates the second deviceis requesting secondary coverage in the mobile communication system. Forexample, the presence indication can correspond to a physical randomaccess channel (PRACH) transmission received by the first device fromthe second device. Furthermore, some such example methods includereporting the presence indication to the first access node. For example,reporting the presence indication to the access node can be performed byincluding an information element indicating receipt of a preamblerepresenting the presence indication in a measurement report, andtransmitting the measurement report to the access node.

Additionally or alternatively, some such example methods can includereceiving information from the access node to configure the firstsignal.

Example methods disclosed herein for a first device to obtain secondarycoverage in a mobile communication system include receiving a secondarycoverage signal from a second device. Such example methods can alsoinclude transmitting a presence indication in response to receiving thesecondary coverage signal from the second device. Such example methodscan further include obtaining secondary coverage from the second deviceafter transmitting the presence indication.

In some such example methods, the mobile communication system supportsLTE functionality, and the secondary coverage signal comprises areference signal transmitted in a center number of resource blocks of anuplink subframe. For example, the center number can be six (6), and thereference signal can transmit a length-62 Zadoff-Chu sequence.

Additionally or alternatively, in some such example methods, thesecondary coverage signal is a first secondary coverage signalindicating that the second device is able to provide secondary coveragein the mobile communication system, and the example methods furtherinclude receiving a second secondary coverage signal from the seconddevice that is to indicate timing associated with when the second deviceexpects to receive the presence indication.

Additionally or alternatively, in some such example methods, thepresence indication corresponds to a PRACH transmission transmitted bythe first device.

Additionally or alternatively, in some such example methods, obtainingsecondary coverage from the second device includes receiving asynchronization signal and system information broadcast by the seconddevice after transmitting the presence indication.

Example methods disclosed herein for an access node to configuresecondary coverage in a mobile communication system include configuringa first device to transmit a secondary coverage signal. In suchexamples, the first device is connected to the access node. Such examplemethods can also include receiving a message from the first devicereporting that a presence indication has been received by the firstdevice from a second device. Such example methods can further includeconfiguring the first device to enable relay node functionality in thefirst device in response to receiving the message reporting the presenceindication.

In some such example methods, configuring the first device to transmitthe secondary coverage signal includes transmitting information to thefirst device. For example, if the first device was functioning as userequipment, the first information can cause the first device to transmitthe secondary coverage signal in addition to continuing to implement itsexisting user equipment function. However, if the user equipment wasalready operating as a relay node, the first information can cause thefirst device to disable the relay node functionality in the first deviceand to start transmitting the secondary coverage signal. For example,the information can include a parameter of the secondary coverage signaland/or a trigger for the same.

Additionally or alternatively, some such example methods further includeconfiguring the first device to transmit a second type of signal that isto indicate resources to be used for sending presence indications, theresources including timing associated with when the first device expectsto receive the presence indication.

Additionally or alternatively, in some such example methods, the mobilecommunication system supports LTE functionality, the presence indicationcorresponds to a PRACH transmission received by the first device fromthe second device, and receiving the message from the first deviceincludes receiving a measurement report from the first device. In somesuch examples, the measurement report includes an information elementindicating that the first device received a preamble representing thepresence indication.

Additionally or alternatively, in some such example methods, configuringthe first device to enable relay node functionality includestransmitting information to the first device to cause the first deviceto stop transmitting the secondary coverage signal and to initiate therelay node functionality. For example, the information can include acell identifier and/or system information to be broadcast by the firstdevice.

These and other example methods, apparatus, systems and articles ofmanufacture (e.g., physical storage media) for providing secondarycoverage in a mobile communication system are disclosed in greaterdetail below.

Secondary coverage in the context of a mobile communication systemrefers to extending the primary coverage provided by the existing accessnodes (e.g., base stations, such as enhanced Node-Bs or eNBs) to devices(e.g., UEs) that are outside the primary coverage area (or are otherwiseunable to obtain service in the primary coverage area) via devices(e.g., UEs) that are in the primary coverage area. For example, inpartial coverage scenarios, one or more devices, referred to asin-coverage devices, are in the network's primary coverage area, whereasone or more other devices, referred to as not-in-coverage devices, arenot in the network's primary coverage area. However, one or more of thenot-in-coverage devices may be within range of one or more of thein-coverage devices.

The secondary coverage functionality disclosed herein can solve theproblem of a lack of mechanisms for efficiently enabling secondarycoverage in existing mobile communication systems, such as existing LTEsystems. For example, secondary coverage functionality as disclosedherein can cause in-coverage devices to enable relay node functionalityto provide secondary coverage by relaying information from accessnode(s) to not-in-coverage devices in a manner that does not causeexcessive interference and/or power consumption. Furthermore, secondarycoverage functionality as disclosed herein can provide mechanisms toindicate the possibility of secondary coverage to a not-in-coveragedevice, without having to speculatively and/or statically enable fullrelay node functionality in one or more of the in-coverage devices.

In the following, the acronym IC represents the phrase “in-coverage” andthe acronym NIC represents the phrase “not-in-coverage.”

Turning to the figures, a block diagram of an example mobilecommunication system 100 capable of providing secondary coverage asdisclosed herein is illustrated in FIG. 1. In the illustrated example,the mobile communication system 100 corresponds to an LTE mobilecommunication system and includes a first example UE 105 incommunication with an example eNB 110 or, more generally, an exampleaccess node 110. The first UE 105A of the illustrated example is in theprimary coverage area of the eNB 110 and is able to obtain networkaccess from the eNB 110. Thus, the first UE 105A is said to bein-coverage because the first UE 105A is obtaining primary coverage fromthe eNB 110 or, in other words, is camped on the eNB 110 such that theUE 105A is able to receive synchronization signal(s) and/or systeminformation from the eNB 110. Accordingly, such a UE is referred toherein as an in-coverage device (ICD) and, as such, the UE 105A is alsoreferred to herein as the ICD 105A. Because the UE 105A is in primarycoverage area of the eNB 110, the UE 105A is able to receive informationfrom the eNB 110 over one or more downlink (DL) channels, and is able totransmit information to the eNB 110 over one or more uplink (UL)channels.

The example system of FIG. 1 also includes second and third example UEs105B and 105C, which are not in the coverage area of the eNB 110 and,thus, are unable to obtain network access from the eNB 110. Furthermore,the UEs 105B and 105C are assumed to be not-in-coverage because the UEs105B and 105C are assumed to not be obtaining primary coverage from anyeNB or other access node(s) of the system 100. In other words, the UEs105B and 105C are not camped and are unable to receive synchronizationsignal(s) and/or system information transmitted by any access node ofthe system 100. Accordingly, such UEs are referred to herein asnot-in-coverage devices (NICDs) and, as such, the UEs 105B and 105C arealso referred to herein as the NICD 105B and NICD 105C, respectively.However, in the illustrated example of FIG. 1, one or both of the UEs105B and 105C are in communication range of the UE 105A and, thus, areable to obtain network access via the in-coverage UE 105A in accordancewith the example secondary coverage functionality disclosed herein.

For example, the in-coverage UE 105A of FIG. 1 includes an example relaynode processor 115A to implement relay node functionality for providingsecondary coverage to one or more of the not-in-coverage UEs 105B-C. Therelay node processor 115A of the illustrated example can implement anytype and/or combination of relay node functionality, such as relay nodefunctionality compliant with the 3GPP LTE specifications. As such, therelay node processor 115A may configure or otherwise cause thein-coverage UE 105A to broadcast one or more signals, such as one ormore synchronization signals, one or more channels containing systeminformation, etc., which the not-in-coverage UEs 105B-C may receive anduse to camp on the in-coverage UE 105A. Furthermore, the relay nodeprocessor 115A may configure or otherwise cause the in-coverage UE 105Ato receive one or more uplink signals and/or channels from thenot-in-coverage UEs 105B-C, which may contain information to be used toregister the not-in-coverage UEs 105B-C with the eNB 110 and/or anetwork served or otherwise accessible via the eNB 110.

In the illustrated example of FIG. 1, the in-coverage UE 105A and thenot-in-coverage UEs 105B-C include respective example secondary coverageprocessors 120A-C to implement secondary coverage functionality asdisclosed herein. In some examples, the eNB 110 includes an examplerelay node controller 125 that also implements secondary coveragefunctionality as disclosed herein. The secondary coverage processors120A-C and the relay node controller 125 implement functionality to, inpart, determine when and/or under what circumstances relay nodefunctionality is to be enabled in ICDs, such as the in-coverage UE 105A.FIG. 2 illustrates an example secondary coverage processor 120, whichmay be used to implement one or more of the secondary coverageprocessors 120A-C of FIG. 1. In the illustrated example of FIG. 2, thesecondary coverage processor 120 includes an example in-coverageprocessor 205 and an example not-in-coverage processor 210. Exampleimplementations and operations of the secondary coverage processors 120and 120A-C, the relay node controller 125, the in-coverage processor 205and the not-in-coverage processor 210 are described in greater detailbelow.

The example UEs 105A-C of FIG. 1 can be implemented by any types and/orcombination of user devices, mobile stations, user endpoint equipment,etc., such as smartphones, mobile telephone devices that are portable,mobile telephone devices implementing stationary telephones, personaldigital assistants (PDAs), etc., or, for example, any other types of UEdevices, or combinations thereof. Also, one or more of the UEs 105A-Cmay correspond to other types of devices capable of operating in thesystem 100. For examples, one or more of the UEs 105A-C may correspondto a relay node, a small cell (e.g., in a cell cluster), amicro/pico/femto cell, etc. Thus, the secondary coverage processors120A-C can be included in any such devices to implement secondarycoverage functionality, and in-coverage and/or not-in-coverageprocessing, as disclosed herein. Accordingly, the term “device” is usedherein in a general sense to refer to any type of equipment capable ofimplementing the example secondary coverage techniques disclosed herein.

Furthermore, although three UEs 105A-C and one eNB 110 are illustratedin FIG. 1, the example system 100 can support any number and/or type(s)of UE devices and/or eNBs. Also, one or more of the not-in-coverage UEsmay include relay node functionality similar or identical to one or moreof the in-coverage UEs, such as the example non-in-coverage UE 105B,which includes an example relay node processor 115B that may be similarto the relay node processor 115A of the in-coverage UE 105A (althoughthe relay node processor 115B may not enable relay node functionality inthe UE 105B until the UE 105B is in a primary coverage area, such aswithin the coverage are of the eNB 110). However, other UEs, such as theUE 105C, may not support relay node functionality and, as such, may notinclude a relay node processor, such as the relay node processor 115A-B.Moreover, the example system 100 may support other communicationstandards and/or functionality in addition to LTE mobile communications.Accordingly, in such systems, the eNB(s) 110 can correspond to anytype(s) and/or number of access node(s), base station(s), etc., and theUEs 105A-C can correspond to any type(s) and/or number of UEs, etc.,supporting such communication standards and/or functionality. Therefore,the example methods, apparatus, articles of manufacture and systemsdisclosed herein for providing secondary coverage in a mobilecommunication system are not limited to implementation in an LTE system,but can be applied in any system supporting the relay of informationamong devices to, for example, control how such information relaying isinitiated.

FIG. 3 illustrates an example DL LTE subframe 310 that can be supportedby the example system 100 of FIG. 1. Control information is transmittedin a control channel region 320 and may include a physical controlformat indicator channel (PCFICH), a physical hybrid automatic repeatrequest (HARQ) indicator channel (PHICH), and a physical downlinkcontrol channel (PDCCH). The control channel region 320 includes thefirst few OFDM (orthogonal frequency division multiplexing) symbols inthe subframe 310. The number of OFDM symbols for the control channelregion 320 is either dynamically indicated by PCFICH, which istransmitted in the first symbol, or semi-statically configured, forexample, in the case of carrier aggregation.

Also referring to FIG. 3, a physical downlink shared channel (PDSCH), aphysical broadcast channel (PBCH), a primary synchronizationchannel/secondary synchronization channel (PSC/SSC), and a channel stateinformation reference signal (CSI-RS) are transmitted in a PDSCH region330 of the subframe 310. DL user data is carried by the PDSCH channelsscheduled in the PDSCH region 330. Cell-specific reference signals aretransmitted over both the control channel region 320 and the PDSCHregion 330.

The PDSCH is used in LTE to transmit DL data to a UE. The PDCCH and thePDSCH are transmitted in different time-frequency resources in a LTEsubframe as shown in FIG. 3. Different PDCCHs can be multiplexed in thePDCCH region 220, while different PDSCHs can be multiplexed in the PDSCHregion 330.

In a frequency division duplex system, a radio frame includes tensubframes of one millisecond each. A subframe 310 includes two slots intime and a number of resource blocks (RBs) in frequency as shown in FIG.3. The number of RBs is determined by the system bandwidth. For example,the number of RBs is 50 for a 10 megahertz system bandwidth.

An OFDM symbol in time and a subcarrier in frequency together define aresource element (RE). A physical RB (PRB) can be defined as, forexample, 12 consecutive subcarriers in the frequency domain and all theOFDM symbols in a slot in the time domain. An RB pair with the same RBindex in slot 0 (represented by reference numeral 340A in FIG. 3) andslot 1 (represented by reference numeral 340B in FIG. 3) in a subframecan be allocated together to the same UE for its PDSCH.

In an LTE system, such as the example system 100, one or more transmitantennas can be supported at the eNB for DL transmissions. Each antennaport can have a resource grid as illustrated in the example of FIG. 4.As shown in FIG. 4, a DL slot includes seven OFDM symbols in the case ofa normal cyclic prefix configuration. A DL slot can include six OFDMsymbols in the case of an extended cyclic prefix configuration. Tosimplify the following discussion, subframes with the normal cyclicprefix configuration will be considered hereinafter, but it should beunderstood that similar concepts are applicable to subframes with anextended cyclic prefix.

FIG. 4 shows an example LTE DL resource grid 410 within each slot 340A/Bin the case of a normal cyclic prefix configuration. The resource grid410 is defined for each antenna port or, in other words, each antennaport has its own separate resource grid 410. Each element in theresource grid 410 for an antenna port corresponds to a respective RE420, which is uniquely identified by an index pair of a subcarrier andan OFDM symbol in a slot 340A/B. An RB 430 includes a number ofconsecutive subcarriers in the frequency domain and a number ofconsecutive OFDM symbols in the time domain, as shown in FIG. 4. An RB430 is the basic unit used for the mapping of certain physical channelsto REs 420.

Similar LTE subframe and resource grid arrangements are used for ULcommunication in the direction from UE(s), such as one or more of theUEs 105A-C, to eNB(s), such as the eNB 110. One such UL communication isa sounding reference signal (SRS), which may be transmitted by a UE andused by a receiving eNB to estimate UL channel quality. Another such ULcommunication is a physical random access channel (PRACH) in which a UEtransmits preambles to gain access to a receiving eNB. Further ULcommunications from a UE to an eNB may include, but are not limited to,a physical uplink shared channel (PUSCH) and a physical uplink controlchannel (PUCCH).

Returning to FIG. 1, the example system 100 supports secondary coverageto extend the primary coverage provided by the existing access nodes(e.g., the eNB 110) to devices (e.g., the UEs 105B and/or 105C) that areoutside the primary coverage area (or are otherwise unable to obtainservice in the primary coverage area) via devices (e.g., the UE 105A)that are in the primary coverage area. Although mobile communicationsystems such as the system 100 provide wide spread network coverage inmany parts of the world via access nodes (e.g., base stations, eNBs,etc.) implementing primary coverage areas, there are and will continueto be scenarios in which a UE cannot obtain network coverage from anynetwork access node. For example, in emergency scenarios, one or moreaccess nodes may fail in some areas, preventing UEs in those areas fromobtaining primary network coverage. Secondary coverage functionality canenable emergency workers in those areas to connect to the network.

Such an example scenario 500 in which secondary coverage functionalitycould be used to enable not-in-coverage devices to still obtain networkaccess is illustrated in FIG. 5. The example scenario 500 corresponds toan example implementation of the system 100 in which four example eNBs110A-D provide primary coverage for example UEs 105A-L. However, in theillustrated example scenario 500, the two eNBs 110C-D have failed or areotherwise not providing primary network coverage. In such an example,secondary coverage functionality as disclosed herein can be used toprovide one or more of the not-in-coverage UEs 105B, C, K and/or L,which would have be in the primary coverage areas of the eNBs 110C-D,with indirect access to one or more of the eNBs A-B still providingexample primary network coverage areas 505A and 505B.

In existing LTE systems, primary network coverage is provided by eNBs.An initial step in obtaining primary coverage is the synchronizationprocess, which starts with a UE detecting the primary synchronizationsequence (PSS) broadcast by an eNB in its PSC. The PSS is transmitted onthe middle 6 RBs of the PSC, and it occupies a single symbol in the timedomain sent twice in a radio frame of 20 timeslots. The PSS isimplemented by a length 62 Zadoff-Chu sequence, which is mapped to the31 subcarriers on each side of a downlink direct current (DC)subcarrier, with the remaining subcarriers within the 6 RB band beingleft unused. The PSS can not only be used for symbol time acquisition,but also for carrier frequency synchronization. In some scenarios, theeNB may also broadcast a secondary synchronization sequence (SSS) in anSSC.

LTE relay node (RN) functionality has been specified in LTE Release 10,to enable not-in-coverage UEs or, equivalently, not-in-coverage devices(NICDs) to connect to the network via RNs. Like an eNB, an RN sends aPSS (and possibly an SSS), and has its own cell identifier to allow anot-in-coverage UE to connect to the network. RNs are configured by ahome subscriber server (HSS) to allow a donor eNB to know that thedevice is allowed to act as a RN. (An HSS can be, for example, a networknode containing subscription-related information to support handlingcalls and communications sessions.) The RNs start by connecting to adonor eNB to obtain suitable configuration, and then switch over to RNoperation.

While the current LTE specifications contemplate RN functionality beingimplemented by ICDs to provide network connections for not-in-coverageUEs or, equivalently, NICDs, no mechanisms are available to determine anappropriate set of ICDs to be enabled to operate as RNs to connect to agiven set of NICDs. Moreover, because the ICDs and NICDs are mobile,there is unlikely to be an unchanging set of appropriate ICDs that canbe statically configured to act as RNs.

One possible approach would be to enable all ICDs to act as RNs.However, there are several disadvantages associated with such anapproach. For example, the ICDs, when acting as RNs, transmit systeminformation in the form of, for example, master information blocks(MIBs) and system information blocks (SIBs), which can be used byreceiving NICDs to register with a donor eNB serving a particular RN. Ifall ICDs in a system were to act as RNs, MIBs and SIBs would betransmitted by all such ICD RNs, which may result in inefficient use ofsystem resources because only a small percentage of ICDs may be in thevicinity of NICDs that can take advantage of the RN functionality. Notethat the system cost of transmitting MIBs and SIBs, althoughconfigurable, may be significant because MIBs and SIBs convey severalhundreds of bytes of information at a conservative coding rate.

Another potential disadvantage associated with simply enabling all ICDsto act as RNs is that the different PSS and SSS combinations from the504 available combinations would need to be provided to the differentICD RNs, which may degrade system performance. For example, fewer PSSand SSS combinations would be left for the eNBs for use in cells thatmay be interfering, which may result in less separation between thecommon reference signals (CRSs) used in these potentially interferingcells.

Yet another potential disadvantage associated with simply enabling allICDs to act as RNs is that RN functionality can increase powerconsumption in the ICDs, thereby reducing battery life.

An example scenario 600, which illustrates the potential disadvantagesof simply enabling all ICDs to act as RNs in an example communicationsystem, such as the system 100, is depicted in FIG. 6. In FIG. 6, thedotted ovals represent the secondary coverage areas of the respectiveICDs 105A and 105D-J, which are acting as RNs. As illustrated in theexample scenario 600, the secondary coverage areas of many of the ICDs105A and 105 D-J are not in the vicinity of any of the NICDs 105B, C. Kor L. or may substantially overlap the primary coverage area afforded bythe eNBs 110A-B. As such, some of the ICDs 105A and 105 D-J may notprovide secondary coverage for any of the NICDs 105B, C, K or L, and theoverhead of providing relay resources for these ICDs 105A, D-J andcoordinating their interference (represented by the overlap in thedotted ovals) will be wasted.

Example secondary coverage functionality disclosed herein, which may beimplemented by the example secondary coverage processors 120, 120A-Band/or the relay node controller 125 described above, provide secondarycoverage mechanisms that reduce the resources provisioned by the networkfor RN functionality and, thus, can alleviate at least some of thedisadvantages of simply enabling all ICDs to act as RNs. In someexamples, the secondary coverage processors 120, 120A-B and/or the relaynode controller 125 implement a secondary coverage solution in which anICD, such as the UE 105A, is to detect NICDs, such as one or more of theUEs 105B-C, before enabling more expensive RN functionality (e.g., interms of increased system resource usage, increased power consumption,etc.) to enable connection with one or more NICDs.

To implement such a secondary coverage solution, in some examples, anICD, such as the UE 105A, is configured by its secondary coverageprocessor, such as the processor 120A, to broadcast one or moresecondary coverage signals (SCSs) to indicate to NICDs in the vicinitythat the ICD is able to provide secondary coverage. In some suchexamples, the ICDs are able to indicate (e.g., implicitly) the resourcesvia which an NICD can indicate its presence after the NICD as detectedthe SCS(s) broadcast by the ICD. Also, in some such examples, an NICDthat detects the SCS(s) broadcast by an ICD sends (e.g., broadcasts) apresence indication (PI) in response to detecting the SCS(s). The NICDmay send the PI, which informs a receiving ICD that an NICD is presentand is requesting secondary coverage, via the indicated resources.Furthermore, in some such examples, the ICD(s) that detected the PI(s)from one or more NICDs are selectively enabled (e.g., by a donor eNB) toenable RN functionality or otherwise provide the NICD(s) withconnection(s) to the network.

An example message sequence diagram 700 illustrating such an examplesolution for providing secondary coverage in the example system 100 ofFIG. 1 is illustrated in FIG. 7. The message sequence diagram 700 of theillustrated example depicts example messages that may be exchangedbetween the example eNB 110, the example ICDs 105A, 705 and the exampleNICDs 105B-C. The eNB 110, the ICD 105A and the NICDs 105B-C aredepicted in the example system 100 of FIG. 1, whereas the ICD 705 is notdepicted in FIG. 1, but is assumed to be in the primary coverage area ofeNB 110.

Turning to FIG. 7, the message sequence diagram 700 begins with the eNB110 sending example messages 710 and 715 to configure the respectiveICDs 105A and 705 to begin broadcasting their respective SCSs. Inresponse to receiving the configuration messages 710 and 715, the ICDs105A and 705 begin broadcasting their respective SCSs 720 and 725, whichmay be received by zero or more NICDs, such as the NICDs 105B and/or105C. In the illustrated example, the NICD 105B detects the SCS(s)broadcast by the ICD 105A. In response to detecting the SCS 720 (whichis depicted by the directed line 730 in FIG. 7), the NICD 105Bbroadcasts a PI 735, which may be received by zero or more ICDs, such asthe ICDs 105A and/or 705.

In the illustrated example of FIG. 7, the ICD 105A detects the PI 735broadcast by the NICD 105B. In response to detecting the PI 735, the ICD105A sends an example measurement report 740 to the eNB 105. Asdescribed in greater detail below, the measurement report 740 informsthe eNB 105 that the ICD 105A has detected the PI 735 from the NICD 105B(although the ICD 105A may not know the identity of the NICD 105B or beable to distinguish between different NICDs sending different PIsignals). In the illustrated example, in response to receiving themeasurement report 740, the eNB 110 sends an example message 745 toconfigure the ICD 105A to enable RN functionality. At block 750, the ICD105A enables its RN functionality, which causes the ICD 105A tobroadcast (corresponding to the directed line 755) synchronizationinformation (e.g., such as by broadcasting a PSS/SSS) and systeminformation (e.g., such as by broadcasting MIBs and SIBs) for possiblereceipt by any NICD(s) in the vicinity of the ICD 105A. In theillustrated example of FIG. 7, the NICD 105B receives thesynchronization and system information broadcast by the ICD 105A anduses this information to camp on the ICD 105A (corresponding to block760) and register with the ICD 105A (corresponding to the directed line765).

Accordingly, to implement the example secondary coverage solutionrepresented by the example message sequence diagram 700 of FIG. 7, anexample LTE-compliant UE can be modified as disclosed herein such that,when the UE is in a primary coverage area and connected to an accessnode (e.g., an eNB), the UE is configured to transmit SCS(s). Forexample, and as described in greater detail below, the UE may transmitits SCS(s) in the resources it would have transmitted SRS(s). Such a UE,when in a primary coverage area, can also be configured to search forPI(s) broadcast by NICD(s), where the PI(s) are to be broadcast usingresources determined with respect to the SCS(s) broadcast by the UE, asdescribed in greater detail. As such, the SCS(s) broadcast by a UEindicate an opportunity (e.g., in terms of resources, such as thetiming) for an NICD to send a PI such that the UE broadcasting the SCSwill be able to receive the PI. Such a UE can further be configured toreport any detected PIs to its serving (or donor) eNB (or some othernetwork node), which will instruct the UE when to start operating as anRN and when to stop operating as an RN.

Additionally, such an LTE-compliant UE can be modified such that, whenthe UE is not in any primary coverage area, the UE is configured tosearch for any SCS(s) in addition to performing any normal searchprocedures to detect the primary coverage offered by an eNB. When an SCSis detected, such a UE can be configured to determine (e.g., directly orindirectly from the received SCS) which resources (e.g., in terms oftiming, etc.) are to be used to transmit a PI, and to transmit the PIvia those resources in response to detecting the SCS. Such a UE canfurther be configured to continue to search for LTE coverage, includeLTE RN secondary coverage that may be provided by an ICD in response tothe UE transmitting its PI.

In the following discussion, it is assumed that ICDs and NICDs operatingin a mobile communication system, such as the system 100 of FIG. 1, areable to be configured to receive UL signals. This is because in some ofthe example solutions for providing secondary coverage disclosed herein,UL signals are used to implement the SCS and PI signals disclosedherein.

FIG. 8 illustrates an example scenario 800 in which the example ICDs105A, 105F, 105G and 105I are transmitting respective example SCSs 805A,805F, 805G and 805I in accordance with the example secondary coveragesolution represented by the example message sequence diagram 700 of FIG.7. In some example scenarios, such as a public safety scenario, one ormore ICDs may provide a secondary network connection to an NICD. Toindicate that a secondary connection is possible, SCS(s) are transmittedfrom such ICDs. In some examples, ICDs may be configured to avoidoperating in a relay mode, such as, for example, operating as a relaynode as defined in Section 4.7 of 3GPP Technical Specification (TS)36.300, V11.3.0 (September 2012), unless the presence of at least oneNICD is detected. 3GPP TS 36.300, V11.3.0 is hereby incorporated byreference in its entirety. Accordingly, such ICDs do not expend relaynode resources and power to send, for example, PSS, SSS, MIBs and/orSIBs unless the presence of at least one NICD is detected.

In some examples, the SCS is derived from an existing UE to eNB signalthat utilizes few resources and does not require significant additionalfunctionality to be added to LTE UEs. For example, an SCS transmissioncan occur in resources that are known (by means of prior configurationor specification in a future LTE standard) to NICDs that may not havebeen in network coverage before. Such an SCS transmission, received bythe NICDs in its range, indicates that the receiving NICDs may be ableto connect to the network via the ICD transmitting the received SCS.

Unlike existing mechanisms for indicating cell coverage, the examplesecondary coverage procedure disclosed herein indicate to NICDs thepossibility of obtaining secondary coverage, without actually providingsecondary coverage initially. Such an approach may result in moreefficient use of system resources because ICDs acting as relay nodes mayutilize more system resources than ICDs transmitting SCSs.

In some examples, an SCS indicates (1) the presence of at least one ICDthat may provide a secondary connection to the network, and (2) theresources that an NICD receiving the SCS may use to indicate thepresence of the NICD. To be detectable above noise and without knowledgeof timing, the SCS may use a sequence, such as a complex symbolsequence, that can be robustly detected. Similar sequences are usedcurrently in LTE, such as, for example, in the generation of the PSS.

Returning to FIG. 8, the example scenario 800 depicts transmission ofthe SCSs 805A, 805F, 805G and 805I by a respective subset of the ICDs105A, 105F, 105G and 105I. In the illustrated example of FIG. 8, thecoverage areas of the SCSs 805A, 805F, 805G and 805I are shown as dashedellipses. In some examples, the SCSs 805A, 805F, 805G and 805I are muchlower in overhead than the primary coverage signals implementing theprimary network coverage areas 505A and 505B. In some examples, the SCSs805A. 805F. 805G and 805I transmitted by the respective ICDs 105A, 105F,105G and 105I do not identify or otherwise distinguish which ICD istransmitting which SCS. Instead, the SCS conveys to a receiving NICDthat an ICD is available in the vicinity, but does not enable the NICDto determine which ICD sent the received SCS. For example, the SCS mayprovide a 1-bit availability indication without any further information,which can help reduce the cost associated with the resources used by theICD for transmitting SCS, as well as the cost of decoding the receivedSCS by the NICD. As such, in some examples, different ICDs may transmitsimilar SCSs.

The following are example procedures associated with transmitting anSCS. In some example scenarios, such as in the example scenario 800 ofFIG. 8, some ICDs, which are connected to one or more cells, may beconfigured to search for (or look for) the presence of NICDs. Such ICDs(e.g., the ICDs 105A, 105F, 105G and 105I of FIG. 8) are said to beconfigured in a lookout mode, to distinguish them from other ICDs (e.g.,the ICDs 105D, 105E, 105H and 105J of FIG. 8) that are not configured toprovide secondary coverage, as well as legacy LTE UEs, devices that areacting as legacy LTE relays, etc.

In some examples, the network may apply one or more criteria to selectthe ICDs to be configured to be in the lookout mode. For example,remaining battery power may be used to avoid selecting ICDs that may notbe able to sustain a secondary coverage connection. Additionally oralternatively, power headroom may be reported by UEs and used by an eNBto select those UEs that are near the cell edge to be in lookout mode.Additionally or alternatively, UE measurement reports may indicate to aneNB that one or more UEs are near other cells despite being near thecurrent cell's edge and, thus, may not be good candidates for thelookout mode (e.g., because it may be unlikely that these UEs will becalled upon to provide secondary coverage as the other cells near theseUEs may be able to provide primary coverage). Additionally oralternatively, a UE's geographic location may be used by the network ina similar manner to determine whether to select the UE for configuringinto lookout mode.

An ICD, such as the ICD 105A, transmits various signals as part of theconnected mode procedures with its serving eNB, such as the eNB 110.Such signals may also be receivable by one or more NICDs, such as theNICDs 105B-C, outside the coverage area of the eNB. In some examples,such signals, which are used for UE-to-eNB communication, may also actas an SCS being transmitted by the ICD. In some such examples, one ormore additional signals may be transmitted by the ICD to indicate whenthe PI is to be transmitted by an NICD.

For example, an ICD may also transmit a further transmission (e.g.,separate from the SCS, which is referred to hereinbelow as an SCSresource signal or SCS-R) that has a property that allows a receivingNICD to determine the resources in which the NICD can indicate its ownpresence (e.g., by transmitting a PI signal). In some examples, thisfurther transmission (e.g., SCS-R) may be configured by the network tobe sent at a particular time with reference to the downlink subframetiming at the ICD.

As discussed above, an NICD can detect an SCS (and/or other ICDtransmissions) to note the availability of secondary coverage via one ormore ICDs in the vicinity. In some examples, multiple ICDs (e.g., theICDs 105G and 105I) may be pre-configured (e.g., based on futurestandardization) or configured by the eNB (e.g., the eNB 110B) totransmit the same signal as their respective SCSs. In other words,multiple ICDs may use the same SCS parameters to generate and transmittheir respective SCSs. Such an arrangement can simplify the detection ofthe SCS at the NICDs, because the receiving NICD does not need todiscriminate between the ICDs in this stage of the secondary coverageprocedure.

The following are example procedures for detecting an SCS at an NICD. Insome examples, NICDs are configured (e.g., by the network),pre-programmed (e.g., during manufacture), or otherwise provided withthe knowledge of the structure of the SCS and its bandwidth with respectto the resources (e.g., frequency bands, symbol times, etc.) in whichthe SCS should be sought. This is analogous to cell synchronization inexisting LTE systems in which the UEs know to look for the cellsynchronization in the center 6 RBs of specified bands.

In some examples, cell search procedures for NICDs are extended toinclude an attempt to detect an SCS if an NICD fails to detect a cellproviding primary network coverage. For example, failure to camp at anystage of the cell synchronization process may be considered a cause foran NICD to attempt to discover an SCS being transmitted by a nearby ICD.Furthermore, in some examples, an NICD may be required to successfullydetect an SCS from an ICD configured to offer secondary coverage beforethe NICD initiates any request for service via a secondary coveragesolution.

As described above and in greater detail below, at the end of the SCSdetection procedure, an NICD is able to determine the presence orabsence of available secondary coverage by determining whether an SCSsignal was detected. For example, the detection of any SCS may indicateto an NICD that secondary coverage is available, whereas not detectingany SCS may indicate to the NICD that secondary coverage is notavailable. Furthermore, if an SCS is detected as present by an NICD, theNICD may then proceed to request secondary coverage connection bysending a PI as described above and in greater detail below.

The following are example procedures for generating and transmittingSCSs and, thus, for an ICD to indicate the availability of secondcoverage. As noted above, in LTE systems, such as the example system100, a UE may transmit an SRS, which can be used by a receiving eNB toestimate UL channel quality. An SRS is similar to a PSS transmitted byan eNB in that both signals are generated based on Zadoff-Chu (ZC)sequences. Accordingly, in some examples, SRS signal generationtechniques form the basis for generating an SCS, because SRS-likesignals can be used to perform symbol timing acquisition and carrierfrequency synchronization at unsynchronized UEs (e.g., NICDs) as iscurrently done with LTE synchronization signals. (See, for example,Section 4.1 in 3GPP TS 36.213, V11.3.0 (June 2013), which isincorporated herein by reference in its entirety.) For example, ICDs(e.g., such as the ICDs 105A, 105F, 105G and 105I) can be configuredwith a sub-band SRS, with the sub-band of the center 6 RBs transmittinga particular sequence that is interpreted by receiving NICDs to be anSCS. While such a signal may look like an SRS to a receiving eNB, to anNICD this signal represented an SCS and indicates the availability ofsecondary coverage. In some examples, NICDs attempt to detect such anSCS in the center 6 RBs in a manner similar to how PSS detection isperformed in a cell detection procedure, but in different resources(e.g., in terms of frequency, symbol time, etc.). Furthermore, in somesuch example cell detection procedures, if a PSS is detected, then theUE attempts to obtain coverage through the cell transmitting the PSSbefore attempting to obtain secondary coverage via attempting to detectan SCS.

Although existing SRS transmissions might be detectable by NICDs and,thus, could be used as an SCS, such existing SRS transmissions can occurusing a variety of base sequences, transmission bandwidths, symbollocations, etc. To simplify the processing at the NICDs, in someexamples, a reduced number of possible SRS transmission parametercombinations are specified (e.g., via eNB configuration, futurestandardization, etc.) for use in generating SCSs. This smaller set ofSRS transmission parameters may be reserved (not used by eNBs that donot provide secondary coverage) and may be obtained as follows.

In some example, the SCS consists of an SRS transmission within themiddle 6 RBs in terms of frequency and occupying a single symbol in thetime domain. For example, the default symbol for this transmission canbe the last symbol of a sub frame that corresponds to the currenttime-domain resources being used by the ICD for SRS transmissions.

In some examples, the SCS is transmitted by an ICD using uplinkresources regardless of whether the system is time division duplex (TDD)or frequency division duplex (FDD). Also, in some examples, the networkmay use a separate ZC sequence for the SCS than is used for the othertransmissions, such as the downlink PSS transmissions. In this way, theresources used for PSS and SCS are separate and, as such, NICDs areunlikely to mistake an SCS for a PSS that is transmitted by the eNB.

In some examples, similar to the existing PSS, a length-62 Zadoff-Chusequence is used to generate the SCS. This allows a length 64 fastFourier transform (FFT) to be used for SCS detection processing, andreduces or eliminates the possibility of confusing the signal with theuplink demodulation reference signals (e.g., because the uplinkreference signals are based on Zadoff-Chu sequences having otherlengths). Since such SCS signals are similar in length and structure tothe existing PSS signals, existing PSS detectors can be modified tosupport SCS detection, where such modification includes accounting forthe removal of the direct current (DC) subcarrier since the SCS istransmitted on the uplink, whereas the PSS is transmitted on thedownlink. For example, the SCS can be transmitted by an ICD using the 31subcarriers on each side of the DC location. Accordingly, in suchexamples, the SCS thus uses both subcarrier combs of the normal SRSresources, instead of splitting alternate subcarriers (e.g., combs)among different UEs as defined in Section 8.2 of 3GPP TS 36.213,V11.3.0.

In some examples, the sequences (e.g., complex symbol sequences) usedfor the SCS are chosen to reduce or have minimum correlation with thePSS, which thereby can reduce the possibility of an NICD confusing theSCS with the existing PSS in a TDD system. For example, a subset of thelength 64 ZC sequences may be reserved (by means of standardization) forSCS, and not used for PSS when secondary coverage is desired.

In some examples, the SRS configuration that is employed as an SCSwithin a cell may be configurable separately from the other SRSconfiguration performed by the eNB serving the cell. Such an arrangementcan allow the serving eNB to vary the parameters of the SCS, such as itsperiodicity, independently of the SRS configuration of the ICDs in thecell.

In some examples, an eNB may separate (in code space and/or time) theSCS transmissions of the ICDs in the cell served by the eNB. Forexample, the eNB may configure different Zadoff-Chu sequences to be usedas the SCS for different ICDs, and/or the eNB may configure differenttime resources for use by different ICDs to transmit the same ordifferent SCS sequences. In such examples, the SCS transmissions areuniquely identifiable to a particular ICD at the eNB and, thus, canstill be used by the eNB for sounding (similar to how an SRS is used),in addition to being used as SCSs. However, in such examples, thedetection of the SCS at the NICDs may incur more complexity than if theSCS transmissions from different ICDs were the same.

In some examples, instead of providing separate resources for SCStransmission to different ICDs, the ICDs within one or more cells usethe same sequence and resources to generate and transmit theirrespective SCSs and, thus, the distinction between the ICDs is performedat a later phase of the secondary connection procedure (e.g., when aconnection request is received from an NICD). In such examples, althoughthe SCS detection at the NICD is made easier, because fewer SCSconfigurations are possible, the eNB is unable reuse the transmitted SCSsignal for sounding (e.g., because a transmitted SCS is not identifiablewith a particular ICD). However, other transmissions of SRS in the SRSresources continue to be usable for sounding. Also, in some examples,the SCSs of different cells are configured differently to allow aconnecting NICD the option to pick the best cell (e.g. eNB) from whichto obtain secondary coverage.

In some examples, the ZC sequence conveyed by SCS has a different lengththan existing SRSs, and/or uses a different number of RBs (6 vs. 4 or 8or more), and/or uses both subcarrier combs instead of alternatesubcarrier combs so that the NICDs can have a low probability ofconfusing an unmodified SRS as an SCS.

The following are example procedures related to SCS power control. Insome examples, an eNB configures or instructs the ICDs within its cellto use a fixed-power for the SCS transmissions. In some examples, theeNB configures a different fixed power setting for SCS transmissions inits cell, which is independent from those used by neighboring eNBs. Insome examples, the eNB configures different fixed SCS power settings fordifferent ICDs within the cell served by the eNB, and these fixed SCSpower settings may be the same as or independent (e.g., different) fromthose used by neighboring eNBs. In some examples, the eNB instructs theICDs to use an open or closed loop power control process in which, forexample, transmit power is set relative to the measured downlinkestimated pathloss. The motivation behind using a transmit power levelrelative to the measured downlink estimated pathloss is that the ICDsthat are most likely to provide secondary coverage to NICDs are thoseICDs that are near the edge of coverage, which implies that such ICDswill have the greatest downlink pathloss values. Meanwhile, those ICDsclose to the eNB would be less likely to provide secondary coverage and,thus, reducing their SCS transmission power can reduce interference bothin-cell and out-of-cell. In some examples, instead of using just theestimated downlink pathloss, the SCS power control can additionally oralternatively utilize the timing advance provided by the eNB to the ICDto account for the effect on pathleoss of obstructions that may existbetween the eNB and the ICD.

FIG. 9 illustrates an example scenario 900 in which the example NICDs105B, 105C, 105K and 105L are transmitting respective example PIs 905B,905C, 905K and 905L in accordance with the example secondary coveragesolution represented by the example message sequence diagram 700 of FIG.7. As described above, in response to detecting an SCS, an NICD thatdesires a secondary connection indicates its presence by transmitting aPI. This PI is signalled on the resources indicated by the received SCSand via which the transmitting ICD will attempt to receive the PI. Forexample, a PI may be sent by an NICD after detection of an SCS, wherethe SCS acts as a marker to the resources where the PI may be sent, andmay also indicate different possible choices of coverage when differentSCS sequences are used.

In some examples, the PI transmitted by an NICD is not directed towardsa particular ICD. For example, in scenarios where multiple ICDs aretransmitting identical SCSs, it may not be possible for an NICD toidentify/distinguish which ICD transmitted a given received SCS. In someexamples, the PI also may not be indicative of the number or identity ofthe NICDs receiving the transmitted SCS(s). For example, a PI signalfrom a particular NICD may be received by multiple ICDs in range, and/orPI signals from multiple NICDs receiving SCSs from different ICDs may bereceived at a given ICD even if that ICD's SCS was not received at someor all of the NICDs associated with the received PIs. In such examples,system resources may be conserved by avoiding the cost of identifyingspecific devices until during the connection setup portion of theexample secondary coverage procedures disclosed herein.

In examples in which the network employs the same SCS sequence and PIsignal for some or all ICDs and NICDs, respectively, the same PI may bereceived by several ICDs, one or more of which may then startfunctioning as relay nodes. Using the PIs received from the NICDs by theICDs and reported by the ICDs to the network, the network may be able todetermine which ICD(s) may be able to serve several NICDs, therebyconserving system resources that would otherwise be required to operatemultiple ICDs as relay nodes.

Returning to FIG. 9, the example scenario 900 depicts transmission ofthe PIs 905B, 905C, 905K and 905L by the NICDs 105B, 105C, 105K and 105Lin response to receiving a previous set of SCS transmissions (e.g., suchas the SCSs 805A, 805F, 805G and 805I illustrated in the examplescenario 800 of FIG. 8). In the illustrated example of FIG. 9, the PIs905B, 905C, 905K and 905L are shown as dashed ellipses representing theregions in which the respective PIs are receivable. In some examples,only some of the ICDs that transmitted SCSs (e.g., such as the exampleICDs 105A, 105F and 105I in FIG. 9) receive PIs and transition intooperating as relay nodes. The other ICDs (e.g., the example ICD 105G inFIG. 9) may remain as ICDs that continue to operate in lookout mode and,thus, continue to transmit their respective SCSs. However, the ICDs(e.g., the ICD 105A, 105F and 105I) that receive PIs report the receiptof the PIs to the network and, thus, are known by the network as havingthe potential to provide secondary coverage to one or more NICDs (e.g.,the NICDs 105B, 105C, 105K and 105L of FIG. 9) that would benefit fromsecondary coverage. The SCS transmissions and the following PItransmissions may occur in consecutive iterations. In some examples, theNICDs that remain out of service wait to receive SCS transmissions, andthen wait for the indicated opportunity to transmit PI. At that time,the NICDs that have successfully decoded an SCS of a previous iterationmay transmit their respective PIs to indicate their presence to any ICDsin the vicinity.

The following are examples of resources and signals that may beconfigured and used to transmit PIs. As described above, NICDs monitorfor SCS transmissions from ICDs to determine an opportunity for sendinga PI signal, such as by determining (e.g., from the received SCS) theresources via which a PI signal may be sent. The ICDs, in turn, monitorthese resources for possible PI transmissions from NICDs. In someexamples, an eNB, such as the eNB 110A, may provide configurationinformation to the ICDs (e.g., the ICD 105A) served by the eNBindicating the sub-frames and/or resources (e.g., RBs, symbols,subcarriers, etc.) on which presence indications can be transmitted. Insome examples, an ICD transmits its SCS such that a receiving NICDdetermines, based on when the SCS was received, when the NICD is to havean opportunity to transmit its PI. For example, NICDs may be configuredto transmit their PI signals a particular number (e.g., 10 or some othernumber) of sub-frames after receipt of an SCS.

In other examples, information concerning the time at which an ICD islooking to receive presence indications from NICDs is conveyed by theICD in a subsequent SCS-R transmission, which may be a variation of theSCS. In such examples, the SCS-R is detectable at the NICDs andimplicitly indicates a time allocated for PI transmission. In suchexamples, NICD that receive an SCS are able to detect the possibility ofobtaining secondary coverage, but wait for reception of a subsequentSCS-R transmission to determine when to transmit its PI. These NICDs mayalso be configured to derive the resources to transmit the PI from thereceived SCS-R. For example, the resources for transmitting PI signalsmay be configured to be a particular number (e.g., 10 or some othernumber) of sub frames after the SCS-R is received by an NICD in thecenter 6 RBs. The benefit of such a mechanism is that, while theperiodic SCSs may be used to indicate coverage, the SCS-R can indicatespecific occasions where resources are reserved for PI. This allows theSCS to be provisioned independently from the PI occasions, which mayrequire more resources because, for example, the PI transmission may notbe aligned to uplink timing and, thus, may benefit from having guardtime reserved for receipt of PI transmissions.

In some examples, particular ZC sequences may be reserved (e.g. byfuture standardization) for SCS and SCS-R. For example, if a length 64ZC sequence is used for the SCS, then one out of the three roots may beused for the SCS, whereas another root may be used for SCS-R. In thismanner, the SCS-R used to signal the opportunity to send the PI isdistinctly detectable at the NICDs relative to the SCS used to signalthe availability of secondary coverage.

In some examples, an eNB may configure ICDs served by the eNB with theperiodicity and/or timing of the resources via which a PI may betransmitted, in addition to providing the timing of the SCS. The timingof the PI resources may be specified by the eNB in terms of ULsub-frames. For example, the timing of the PI resources may be indicatedby the eNB to coincide with the eNB's own PRACH allocations if PRACH isused to transmit PI signals, as described in further detail below.

As described above, the PI signal indicates, to a receiving ICD, thepresence of at least one NICD. However, in some examples, the PIprovides no further identification or discrimination of the particularNICD that transmitted the PI.

Also, in some examples, the NICD derives PI timing from an SCS or otherICD-to-NICD transmission received from an ICD. This is because an NICDis not in a primary coverage area yet and, thus, has not received a timealignment command yet from the network. Accordingly, an NICD mayestablish PI timing and transmit a PRI signal in a manner analogous tohow a UE establishes timing when transmitting on PRACH.

Moreover, in some examples, the NICD is configured to use a particularPRACH preamble to signal its PI on sub-frames specified as havingresources reserved for PI transmission. In such examples, a particularPRACH preamble, referred to herein as the PI preamble (PIP), or set ofPIPs, is reserved for the purpose of conveying PIs in a cell and, thus,is not used by UEs for other PRACH transmissions in the coverage area ofthe that cell. For example, NICDs may be configured (e.g., when the NICDwas previously in-coverage) or pre-programmed (e.g. based on a standardspecification) with the PIP(s) to be used to convey their respectivePIs, and the same or different PIPs may be used for different NICDs.

In some examples in which PIPs are used to convey PIs, the ICDsconfigured by the eNB to transmit SCSs in the cell attempt to decode theUL PRACH in the particular sub-frames where the ICDs are configured tosearch for PIPs. This is because, in such examples, an NICD that is ableto decode an SCS and desires secondary coverage will transmit its PIP ina PRACH at an opportunity based on the timing and frequency derived fromthe received SCS (or derived from an SCS-R associated with the receivedSCS), as described above.

In some examples, the network can amortize the overhead of reserving aPRACH allocation for the sending the PI signal by using existing PRACHallocations, where the PRACH configuration is such that at least the PIPis not configured to be used by ICDs. In such examples, the ICDs thatare configured to attempt to detect a PIP are not able to receive DLdata in that sub frame in an FDD system.

In some examples, because of the possibility that the NICDs have not yetbeen in any primary coverage area and, thus, have not had an opportunityto obtain any network configuration prior to detecting an SCS, defaultvalues for the RACH parameters used to send PIPs, such as the rootsequence and power ramping steps, may be pre-programmed (e.g. based on afuture standard specification) in the NICDs.

In some examples, an eNB also configures, or indicates dynamically, theresources to be used by ICDs to report detection of PIs from NICDs. Sucha report may be in the form of a message indicating detection of PI. Forexample, in the case of the PI signals being implemented by PRACHtransmissions, the report of a received PIP may be conveyed by the ICDto the eNB using the example radio resource control (RRC) message ofTable 1.

TABLE 1 PIResult ::=SEQUENCE {   pip-Recv SEQUENCE {     pipPI-BACH-Preamble OPTIONAL,   } }

An example of the PI-RACH-Preamble information element (IE) of Table 1is illustrated in Table 2.

TABLE 2 -- ASN1START PI-RACH-Preamble ::= SEQUENCE {   ra-PreambleIndex   INTEGER (0..63),   ra-PRACH-MaskIndex    INTEGER (0..15) } --ASN1STOP ra-PRACH-Maskindex Explicitly signaled PRACH Mask Index forRandom Access (RA) Resource selection as specified in, for example, 3GPPTS 36.321, V11.3.0 (July 2013), which is hereby incorporated byreference in its entirety. ra-Preambleindex Explicitly signaled RandomAccess Preamble for RA Resource selection as specified in, for example,3GPP TS 36,321, V11.3.0.

In some examples, an ICD may additionally or alternatively notify theeNB of a received PIP by means of additional signaling (e.g., such asthat associated with Tables 1 and 2) included within a measurementreport sent to the eNB.

FIG. 10 illustrates an example scenario 1000 in which the example ICDs105A, 105F and 105I are configured to enable RN functionality inaccordance with the example secondary coverage solution represented bythe example message sequence diagram 700 of FIG. 7. In the illustratedexample of FIG. 10, by using the reports of PIs that were detected byICDs configured to send SCSs, the network is able to discriminate thoseone or more ICDs that have a high likelihood of being able to providesecondary coverage to one or more NICDs. In such examples, theappropriate ICDs can be identified, selected and configured to providesecondary coverage as follows.

For example, after a PI from an NICD is received by one or more ICDsoperating in lookout mode, the ICDs indicate the PI reception, possiblyalong with measured characteristics of the received PI signal, to theirserving eNB. The eNB then selects (e.g., based on one or more criteria,such as number of PIs reported as being received in a particular timeinterval, strength of the PI(s) reported as received, number of nearbyICDs also reporting PI(s), and/or as otherwise described herein) andsignals to one or more of the ICDs to exit the lookout mode and to startfunctioning as LTE relay nodes. In accordance with the LTEspecifications, these ICDs are assigned cell identifiers by the eNB,along with the parameters for the MIB and SIB information to betransmitted by the ICDs when functioning as relay nodes. In someexamples, the relay nodes operate on one or more carrier frequencies toconnect with the NICDs that are different from the carrier frequency orfrequencies used by the eNB to provide primary coverage in the cell. TheICD(s) configured to be relay nodes then transmit their respective cellsynchronization signals (e.g., PSS/SSS) and MIB and SIBs based on theconfiguration received from the eNB, in the same manner as existing LTErelays. However, the example secondary coverage techniques disclosedherein are not limited to relays operating in accordance with existingLTE relay specification. Instead, it is sufficient that the selectedICDs function as relay nodes in a generic sense in accordance with anycommunication technique capable of supporting secondary coverage throughrelays or similar mechanisms.

Returning to the FIG. 10, the example scenario 1000 depicts an exampleoperation in which, based on one or more of the selection criteriadisclosed above, the network selects ICDs 105A, 105F and 105I to beconfigured as relay nodes providing secondary coverage. The relay nodefunctionality of the selected ICDs 105A, 105F and 105I is then enabledsuch that these ICDs are able to implement respective example relay nodecoverage areas 1005A, 1005F and 1005I in the illustrated example.Different cell identification information may be configured for two ormore of the ICDs 105A, 105F and 105I acting as relay nodes. The cellidentifiers may then be used by the NICD(s) in the vicinity of the ICDs105A, 105F and 105I to determine the best ICD from which to obtainsecondary coverage. For example, the NICD 105K may detect the cellsynchronization signals and MIB/SIBs broadcast by both the ICDs 105F and105I operating as relay nodes, and use the respective cell identifiersfor these ICDs to determine to which of the ICDs 105F and 105I the NICD105K is to request secondary coverage.

In some examples, after transmitting their respective PIs, the NICDsresume or continue to perform their respective cell search procedures tofind new cells that have been started due to one or more ICDs beingconfigured to start acting as relay nodes. In such examples, the NICDscan connect to the network via such newly-established relay node(s),possibly in a manner similar to how the NICDs would connect to existingLTE cells. In some examples, the eNB further indicates to thein-coverage UEs in range of the newly enabled relay nodes that theirassociated relay cells are to be avoided, which can help reduce thepower consumption of the ICDs that are now functioning as relays.

In some examples, those ICDs that were not selected to become relaynodes remain in lookout mode and, thus, may continue the process oftransmitting their respective SCS signals and attempting to detectreceived PI signals. Also, one or more ICDs that had switched over torelay mode, but either did not receive a RACH from any NICDs or that areno longer serving any NICDs, may be switched back by the network (e.g.via eNB signalling) to the lookout mode as ICDs or to connected mode asin-coverage UEs.

FIG. 11 illustrates an example scenario 1100 in which the example ICDs105A, 105F and 105I are configured to enable RN functionality inaccordance with the example secondary coverage solution represented bythe example message sequence diagram 700 of FIG. 7. The example scenario1100 also illustrates corresponding example connections, represented bybi-directional arrows, that are used to provide the NICDs 105B, 105C,105K and 105L with secondary coverage to the network. Also, although notshown, in some examples one or more of the ICDs that were configured toenable relay node functionality may revert from relay node mode back tolookout mode because those ICD(s) ultimately were not needed to connectto any NICDs (e.g., after a timeout period). For example, the networkcan monitor the ICDs that have been configured to act as relay nodesafter reporting a PI, but which did not establish a connection to anyNICD. In such examples, the network, or the ICDs themselves, can use atimer to determine when to revert back to being an ICD in the lookoutmode (e.g., if no connection request is received from an NICD within aparticular timeout period). Further, the measurement reports from theNICDs that have connected to the ICDs acting as relay nodes can be usedby the network to determine if any other cells (e.g., primary cellsimplemented by eNBs and/or secondary cells implemented by relay nodes)are measurable by the NICD. This information can be conveyed to thedonor eNB that is to provide secondary coverage, and the donor eNB canthen determine which coverage of the ICDs in relay node mode isnon-overlapping and, thus, is able to reuse the resources between therelay nodes, where possible.

In some examples, a reserved PRACH preamble, called the secondarycoverage PRACH preamble (SCPP), which is also a ZC sequence like thePSS, may be used instead of an SRS-like signal to implement the SCSdisclosed above. Such an SCPP can be indicated as reserved for SCS inthe SIB broadcast by an eNB, and/or specified in RRC configuration sentby the eNB to an ICD. In such examples, the eNB disregards SCPPsreceived from a UE. Instead, the NICDs look to decode a number (e.g.,one or more) of these SCPPs on PRACHs in a specified time to therebyinfer that secondary coverage is available. In some examples, the PRACHsare transmitted at a particular time offset from the start of the PRACHtime resources, in order to provide a consistent timing of the receivedsignal at the NICDs.

Note that the NICDs need not have an accurate notion of UL timing beforetransmitting the PI. A coarse-grained notion of DL timing suffices. Somultiple SCSs received from ICDs (e.g., which may be connected to thesame or different eNBs) at different times allows an NICD to pick one ormore of the SCS to which to respond. The SCPP, possibly along with someadditional parameters, such as the root sequence, may be configured orpre-programmed in NICDs, whose cell search procedure is amended toinclude searching for the one (or a few) ZC sequences corresponding tothe SCPP. Further, another reserved preamble, which is similarlyconfigured in the NICDs and ICDs, may be used as the SCS-R definedabove.

In some examples, different ICDs are configured with different SCSs(and/or possibly SCS-Rs) to allow an NICD that receives an SCS todetermine a cell (e.g., donor eNB) and/or an ICD to which the NICDprefers to connect to obtain secondary coverage. Such examples mayemploy a larger set of possible SCS (and possibly SCS-R) signals to bedecoded at the NICD, but allow the network to require fewer ICDs toswitch to relay mode by providing the NICDs a way to discriminatebetween the ICDs (e.g., based on signal quality) when requesting asecondary coverage connection. In some examples, the PIs correspondingto the different NICDs are may also be distinct. In some examples,distinct SCSs may be provided to some subsets of ICDs to indicatedifferent classes of secondary coverage.

A consideration in the design of the SCS is that it should bedistinguishable from PSS/SSS that is used for primary coverage. This isone reason why the example secondary coverage procedures disclosedherein utilize an SCS that is sent in the UL resources. However, adistinction between the SCS and PSS/SSS may not be an issue at the stageof initial cell search, because legacy UEs are expected to be able tohandle the existence of PSS/SSS of cells that may not allow them to campor RACH. As such, in some examples, the same resources as PSS/SSS may beused for transmitting the SCS (e.g. such as the SCS being transmitted inthe DL spectrum of an FDD system). In other examples that are used in aTDD system, or where SCS transmission occurs in DL spectrum of an FDDsystem, some power consumed in legacy UEs for cell search may be savedby specifying that the SCS is to be located outside the center 6 RBs.Since the NICDs are non-legacy, the frequency resources for such SCS maybe pre-programmed or configured.

In some examples, an SRS transmission from the NICD may be used for thePI instead of a PRACH PIP, as disclosed above. The parameters for suchan SRS to be used as a PI, which may include the transmit power and theparticular sequence (e.g., complex symbol sequence), can bepreconfigured in both the NICD and the ICDs. Since the transmit timingof the NICD is based on the SCS, and no time advance like command hasbeen sent to the NICD before its transmission of the PI, the eNBallocates guard time and frequency around the expected PI transmission.Accordingly, in such examples, ICDs may be expected to attempt to decodethe PI signal by trying a few possibilities of transmission timing.

FIG. 12 depicts an example timing diagram 1200 illustrating exampletiming relationships between example SCSs and associated example PIsconveyed in accordance with the second example secondary coveragesolution represented by the example message sequence diagram 700 of FIG.7. In the example timing diagram 1200 of FIG. 2, the example ICD 105Atransmits a first example SCS 1205 at a first time, and the example ICD705 transmits a second example SCS 1210 at a second time. The ICDs 105Aand 705 are receiving primary coverage from the example eNB 110 and,thus, the timing of their UL transmissions are aligned with the ULtiming of the eNB 110. Accordingly, the SCSs 1205 and 1210 aretransmitted by the respective ICDs 105A and 705 at times relative toeach other such that the SCSs 1205 and 1210 arrive at the same time atthe eNB 110 (which is represented by the respective downward directedarrows 1215 and 1220).

However, the example NICD 105B of FIG. 12 may not be located at the samedistances from the respective ICDs 105B and 705 as is the eNB 110.Accordingly, the SCSs 1205 and 1210 may be received by the NICD 105Bseparated in time by at most the cell's path delay. The reception of theSCSs 1205 and 1210 at the NICD 105B is represented by the respectivedownward directed arrows 1225 and 1230 in the example timing diagram1200. In the illustrated example, the NICD 105B transmits respectiveexample PIs 1235 and 1240 in response to receiving the SCSs 1205 and1210. However, the PIs 1235 and 1240 may be offset due to thecorresponding offset between the received SCS signals 1225 and 1230.However, by using UL resources for PI transmission that include guardbands, such as the example PRACH guard bands 1245 and 1250 associatedwith PRACH transmissions, it is possible to allow for such path delaysand accommodate the different times at which the PI transmissions fromNICDs may be received at different ICDs, as illustrated in the exampletiming diagram 1200 of FIG. 12.

While example manners of implementing the example system 100, theexample UEs 105A-L, the example access nodes 110 and 110A-D, the examplerelay node processors 115A-B, the example secondary coverage processors120A-C, the example in-coverage processor 205 and the examplenot-in-coverage coverage processor 210 have been illustrated in FIGS.1-12, one or more of the elements, processes and/or devices illustratedin FIGS. 1-12 may be combined, divided, re-arranged, omitted, eliminatedand/or implemented in any other way. Further, the example system 100,the example UEs 105A-L, the example access nodes 110 and/or 110A-D, theexample relay node processors 115A-B, the example secondary coverageprocessors 120A-C, the example in-coverage processor 205 and/or theexample not-in-coverage coverage processor 210 of FIGS. 1-12 may beimplemented by hardware, software, firmware and/or any combination ofhardware, software and/or firmware. Thus, for example, any of theexample system 100, the example UEs 105A-L, the example access nodes 110and/or 110A-D, the example relay node processors 115A-B, the examplesecondary coverage processors 120A-C, the example in-coverage processor205 and/or the example not-in-coverage coverage processor 210 could beimplemented by one or more analog or digital circuit(s), logic circuits,programmable processor(s), application specific integrated circuit(s)(ASIC(s)), programmable logic device(s) (PLD(s)) and/or fieldprogrammable logic device(s) (FPLD(s)). When reading any of theapparatus or system claims of this patent to cover a purely softwareand/or firmware implementation, at least one of the example system 100,the example UEs 105A-L, the example access nodes 110 and/or 110A-D, theexample relay node processors 115A-B, the example secondary coverageprocessors 120A-C, the example in-coverage processor 205 and/or theexample not-in-coverage coverage processor 210 is/are hereby expresslydefined to include a tangible computer readable storage device orstorage disk such as a memory, a digital versatile disk (DVD), a compactdisk (CD), a Blu-ray disk, etc. storing the software and/or firmware.Further still, the example system 100, the example UEs 105A-L, theexample access nodes 110 and/or 110A-D, the example relay nodeprocessors 115A-B, the example secondary coverage processors 120A-C, theexample in-coverage processor 205 and the example not-in-coveragecoverage processor 210 of FIGS. 1-12 may include one or more elements,processes and/or devices in addition to, or instead of, thoseillustrated in FIGS. 1-12, and/or may include more than one of any orall of the illustrated elements, processes and devices.

Flowcharts representative of example processes for implementing theexample system 100, the example UEs 105A-L, the example access nodes 110and/or 110A-D, the example relay node processors 115A-B, the examplesecondary coverage processors 120A-C, the example in-coverage processor205 and/or the example not-in-coverage coverage processor 210 of FIGS.1-12 are shown in FIGS. 13-15. In these examples, the processes may beimplemented by one or more programs comprising machine readableinstructions for execution by a processor, such as the processor 1612shown in the example processor platform 1600 discussed below inconnection with FIG. 16. The one or more programs, or portion(s)thereof, may be embodied in software stored on a tangible computerreadable storage medium such as a CD-ROM, a floppy disk, a hard drive, adigital versatile disk (DVD), a Blu-ray disk™, or a memory associatedwith the processor 1612, but the entire program or programs and/orportions thereof could alternatively be executed by a device other thanthe processor 1612 and/or embodied in firmware or dedicated hardware(e.g., implemented by an ASIC, a PLD, an FPLD, discrete logic, etc.).Also, one or more of the processes represented by the flowcharts ofFIGS. 13-15, or one or more portion(s) thereof, may be implementedmanually. Further, although the example processes are described withreference to the flowcharts illustrated in FIGS. 13-15, many othermethods of implementing the example system 100, the example UEs 105A-L,the example access nodes 110 and/or 110A-D, the example relay nodeprocessors 115A-B, the example secondary coverage processors 120A-C, theexample in-coverage processor 205 and/or the example not-in-coveragecoverage processor 210 may alternatively be used. For example, withreference to the flowcharts illustrated in FIGS. 13-15, the order ofexecution of the blocks may be changed, and/or some of the blocksdescribed may be changed, eliminated, combined and/or subdivided intomultiple blocks.

As mentioned above, the example processes of FIGS. 13-15 may beimplemented using coded instructions (e.g., computer and/or machinereadable instructions) stored on a tangible computer readable storagemedium such as a hard disk drive, a flash memory, a read-only memory(ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, arandom-access memory (RAM) and/or any other storage device or storagedisk in which information is stored for any duration (e.g., for extendedtime periods, permanently, for brief instances, for temporarilybuffering, and/or for caching of the information). As used herein, theterm tangible computer readable storage medium is expressly defined toinclude any type of computer readable storage device and/or storage diskand to exclude propagating signals. As used herein, “tangible computerreadable storage medium” and “tangible machine readable storage medium”are used interchangeably. Additionally or alternatively, the exampleprocesses of FIGS. 13-15 may be implemented using coded instructions(e.g., computer and/or machine readable instructions) stored on anon-transitory computer and/or machine readable medium such as a harddisk drive, a flash memory, a ROM, a CD, a DVD, a cache, a RAM and/orany other storage device or storage disk in which information is storedfor any duration (e.g., for extended time periods, permanently, forbrief instances, for temporarily buffering, and/or for caching of theinformation). As used herein, the term non-transitory computer readablemedium is expressly defined to include any type of computer readabledevice or disk and to exclude propagating signals. As used herein, whenthe phrase “at least” is used as the transition term in a preamble of aclaim, it is open-ended in the same manner as the term “comprising” isopen ended. Also, as used herein, the terms “computer readable” and“machine readable” are considered equivalent unless indicated otherwise.

An example process 1300 that may be executed to implement the examplein-coverage processor 205 of the example secondary coverage processor120 of FIG. 2 is illustrated in FIG. 13. As disclosed above, thesecondary coverage processor 120 of FIG. 2 may be included in a UE, suchas the UEs 105A-C, and the in-coverage processor 205 may be used toimplement ICD processing in such a UE. For convenience and without lossof generality, operation of the example process of 1300 is describedfrom the perspective of the secondary coverage processor 120 beingincluded in the example ICD 105A. With reference to the precedingfigures and associated written descriptions, the example process 1300 ofFIG. 13 begins execution at block 1305 at which the in-coverageprocessor 205 of the ICD 105A obtains any secondary coverageconfiguration information, such as any information to configure SCSgeneration/transmission, SCS-R generation/transmission, PI timing, etc.,from a serving access node, such as the eNB 110. The configurationinformation received at block 1305, or configuration receivedthereafter, can also instruct the in-coverage processor 205 to cause theICD 105A to begin transmitting its SCS, as described above.

At block 1310, the in-coverage processor 205 causes the ICD 105A totransition to the lookout mode and begin transmitting its SCS (andSCS-R, if configured) to indicate that the ICD 105A is able to providesecondary coverage, as described above. At block 1315, the in-coverageprocessor 205 performs PI detection to attempt to detect any PIs thatmay be received from any NICDs, such as from one or more of the NICDs105B-C. Such PIs, if detected, may or may not be received in response tothe SCS transmission(s) initiated at block 1310, as described above. Atblock 1318, the in-coverage processor 205 determines whether any PI(s)have been received. If at least one PI was received (block 1318), thenat block 1320 the in-coverage processor 205 causes the ICD 105A toreport the detection of the PI(s) at block 1315 to the eNB 110 servingthe ICD 105A, as described above. Otherwise, processing returns to block1310.

At block 1325, the in-coverage processor 205 determines whether the ICD105A has received any relay node configuration from the eNB 110 inresponse to the PI(s) reported at block 1320. If the ICD 105A has notreceived any relay node configuration information (block 1325), then thein-coverage processor 205 causes the ICD 105A to continue operating inlookout mode and, thus, processing returns to block 1310 and blockssubsequent thereto. However, if the ICD 105A has received relay nodeconfiguration information (block 1325), then at block 1330 thein-coverage processor 205 obtains the relay node configurationinformation from the eNB 110, as described above. Then, at block 1335,the in-coverage processor 205 causes the ICD 105A to stop its SCStransmissions(s) and exit the lookout mode, and at block 1340, thein-coverage processor 205 causes the relay node processor 115A of theICD 105A to enable relay node functionality, as described above.

An example process 1400 that may be executed to implement the examplenot-in-coverage processor 210 of the example secondary coverageprocessor 120 of FIG. 2 is illustrated in FIG. 14. As disclosed above,the secondary coverage processor 120 of FIG. 2 may be included in a UE,such as the UEs 105A-C, and the not-in-coverage processor 210 may beused to implement NICD processing in such a UE. For convenience andwithout loss of generality, operation of the example process of 1400 isdescribed from the perspective of the secondary coverage processor 120being included in the example NICD 105B. With reference to the precedingfigures and associated written descriptions, the example process 1400 ofFIG. 14 begins execution at block 1405 at which the not-in-coverageprocessor 210 of the NICD 105B obtains any secondary coverageconfiguration information, such as any information to configure SCSdetection, SCS-R detection, PI generation/transmission, etc., asdescribed above. For example, the configuration information received atblock 1405 may be pre-programmed and/or received from an access node ata previous time during which the NICD 105B was connected to the network.

At block 1408, the not-in-coverage processor 210 causes the NICD 105B toperform SCS detection to detect one or more SCS transmissions from oneor more ICDs, such as the ICD 105A, as described above. If an SCS isdetected (block 1408), then at block 1410 the not-in-coverage processor210 receives the detected SCS. At block 1415, the not-in-coverageprocessor 210 causes the NICD 105B to transmit one or more PIs inresponse to the SCS transmission(s) received at block 1410, as describedabove. At block 1420, the not-in-coverage processor 210 determineswhether the NICD 105B has subsequently detected any broadcastedsynchronization signal(s) and/or system information indicative of thepresence of a cell. If such information indicative of the presence of acell is not detected (block 1420), then the not-in-coverage processor210 causes the NICD 105B to continue attempting to detect SCStransmission(s) from nearby ICD(s) and, thus, processing returns toblocks 1410 and the blocks subsequent thereto. However, informationindicative of the presence of a cell is detected (block 1420), then atblock 1425 the not-in-coverage processor 210 causes the NICD 105B tocamp on the cell associated with the received synchronization signal(s)and/or system information. For example, and as described above, the cellat block 1425 may be implemented by an ICD, such as the ICD 105A, whichwas configured to operate as a relay node to provide secondary coveragein response to the PI(s) transmitted at block 1415.

An example process 1500 that may be executed to implement the examplerelay node controller 125 of an example access node, such as the exampleeNB 110 of FIG. 1, is illustrated in FIG. 15. As disclosed above, therelay node controller 125 is included in an example access node, such asthe eNB 110, to control whether relay node functionality is configuredin an ICD served by the access node, such as the ICD 105A. Forconvenience and without loss of generality, operation of the exampleprocess of 1500 is described from the perspective of the relay nodecontroller 125 being included in the example eNB 110. With reference tothe preceding figures and associated written descriptions, the exampleprocess 1500 of FIG. 15 begins execution at block 1505 at which therelay node controller 125 causes the eNB 110 to transmit (e.g., viabroadcast signaling, unicast dedicated signaling, etc.) secondarycoverage configuration information, such as any information to configureSCS generation/transmission, SCS-R generation/transmission, PI timing,etc., to one or more ICDs, such as the ICD 105A, being served by the eNB110. The configuration information transmitted at block 1505 alsoinstructs the receiving ICD(s) to enter lookout mode and begintransmitting their respective SCS(s), as described above.

At block 1510, the relay node controller 125 of the eNB 110 receives oneor more reports from one or more ICDs, such as the ICD 105A, reportingthe detection of one or more PIs from one or more NICDs, such as one ormore of the NICDs 105B-C, as described above. At block 1515, the relaynode controller 125 evaluates one or more criteria, as described above,to determine whether to configure any ICD associated with a PI reportreceived at block 1510 as a relay node that is to provide secondarycoverage. If no ICD is to be configured as a relay node (block 1515),then the relay node controller 125 waits to receive further PI reportsfrom the ICD(s) and, thus, processing returns to block 1510. However, ifat least one ICD is to be configured as a relay node (block 1515), thenat block 1520 the relay node controller 125 causes the eNB 110 to sendrelay node configuration to one or more of the ICDs associated with thePI report(s) received at block 1510. For example, and as describedabove, the relay node configuration sent at block 1520 can cause areceiving ICD to stop its SCS transmissions(s), exit the lookout modeand enable relay node functionality to provide secondary coverage to anyNICDs in the vicinity of the ICD, which may or may not include an NICDfrom which the ICD received a PI.

FIG. 16 is a block diagram of an example processor platform 1600 capableof executing the processes of FIGS. 13-15 to implement the examplesystem 100, the example UEs 105A-L, the example access nodes 110 and/or110A-D, the example relay node processors 115A-B, the example secondarycoverage processors 120A-C, the example in-coverage processor 205 and/orthe example not-in-coverage coverage processor 210 of FIGS. 1-12. Theprocessor platform 1600 can be, for example, a server, a personalcomputer, a mobile device (e.g., a cell phone, a smart phone, a tablet),a personal digital assistant (PDA), an Internet appliance, a DVD player,a CD player, a digital video recorder, a Blu-ray player, a gamingconsole, a personal video recorder, a set top box a digital camera, orany other type of computing device.

The processor platform 1600 of the illustrated example includes aprocessor 1612. The processor 1612 of the illustrated example ishardware. For example, the processor 1612 can be implemented by one ormore integrated circuits, logic circuits, microprocessors or controllersfrom any desired family or manufacturer.

The processor 1612 of the illustrated example includes a local memory1613 (e.g., a cache) (e.g., a cache). The processor 1612 of theillustrated example is in communication with a main memory including avolatile memory 1614 and a non-volatile memory 1616 via a link 1618. Thelink 1518 may be implemented by a bus, one or more point-to-pointconnections, etc., or a combination thereof. The volatile memory 1614may be implemented by Synchronous Dynamic Random Access Memory (SDRAM),Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory(RDRAM) and/or any other type of random access memory device. Thenon-volatile memory 1616 may be implemented by flash memory and/or anyother desired type of memory device. Access to the main memory 1614,1616 is controlled by a memory controller.

The processor platform 1600 of the illustrated example also includes aninterface circuit 1620. The interface circuit 1620 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 1622 are connectedto the interface circuit 1620. The input device(s) 1622 permit(s) a userto enter data and commands into the processor 1612. The input device(s)can be implemented by, for example, an audio sensor, a microphone, acamera (still or video), a keyboard, a button, a mouse, a touchscreen, atrack-pad, a trackball, a trackbar (such as an isopoint), a voicerecognition system and/or any other human-machine interface.

One or more output devices 1624 are also connected to the interfacecircuit 1620 of the illustrated example. The output devices 1624 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay, a cathode ray tube display (CRT), a touchscreen, a tactileoutput device, a light emitting diode (LED), a printer and/or speakers).The interface circuit 1620 of the illustrated example, thus, typicallyincludes a graphics driver card, a graphics driver chip or a graphicsdriver processor.

The interface circuit 1620 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem and/or network interface card to facilitate exchange of data withexternal machines (e.g., computing devices of any kind) via a network1626 (e.g., an Ethernet connection, a digital subscriber line (DSL), atelephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 1600 of the illustrated example also includes oneor more mass storage devices 1628 for storing software and/or data.Examples of such mass storage devices 1628 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAID(redundant array of independent disks) systems, and digital versatiledisk (DVD) drives.

Coded instructions 1632 corresponding to the instructions of FIGS. 13-15may be stored in the mass storage device 1628, in the volatile memory1614, in the non-volatile memory 1616, in the local memory 1613 and/oron a removable tangible computer readable storage medium, such as a CDor DVD 1636.

Also, as used herein, the term “node” broadly refers to any connectionpoint, such as a redistribution point or a communication endpoint, of acommunication environment, such as a network. Accordingly, such nodescan refer to an active electronic device capable of sending, receiving,or forwarding information over a communications channel. Examples ofsuch nodes include data circuit-terminating equipment (DCE), such as amodem, hub, bridge or switch, and data terminal equipment (DTE), such asa handset, a printer or a host computer (e.g., a router, workstation orserver). Examples of local area network (LAN) or wide area network (WAN)nodes include computers, packet switches, cable modems, digitalsubscriber line (DSL) modems, wireless LAN (WLAN) access points, etc.Examples of Internet or Intranet nodes include host computers identifiedby an Internet Protocol (IP) address, bridges, WLAN access points, etc.Likewise, examples of nodes in cellular communication include basestations, relays, base station controllers, radio network controllers,home location registers, Gateway GPRS Support Nodes (GGSN), Serving GPRSSupport Nodes (SGSN), Serving Gateways (S-GW), Packet Data NetworkGateways (PDN-GW), etc.

Other examples of nodes include client nodes, server nodes, peer nodesand access nodes. As used herein, a client node may refer to wirelessdevices such as mobile telephones, smart phones, personal digitalassistants (PDAs), handheld devices, portable computers, tabletcomputers, and similar devices or other user equipment (UE) that hastelecommunications capabilities. Such client nodes may likewise refer toa mobile, wireless device, or conversely, to devices that have similarcapabilities that are not generally transportable, such as desktopcomputers, set-top boxes, sensors, etc. A server node, as used herein,may refer to an information processing device (e.g., a host computer),or series of information processing devices, that perform informationprocessing requests submitted by other nodes. As used herein, a peernode may sometimes serve as a client node, and at other times, a servernode. In a peer-to-peer or overlay network, a node that actively routesdata for other networked devices as well as itself may be referred to asa supernode. An access node, as used herein, may refer to a node thatprovides a client node access to a communication environment. Examplesof access nodes include, but are not limited to, cellular network basestations such as evolved Node-Bs (eNBs), wireless broadband (e.g., WiFi,WiMAX, etc) access points, relay nodes, cluster head devices, mobilestations, etc., which provide corresponding cell and/or WLAN coverageareas, etc.

Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

1-87. (canceled)
 88. A method, comprising: transmitting, from a networknode to a first terminal, secondary coverage configuration information;receiving, at the network node and from the first terminal, a presenceindication (PI) report of a second terminal; determining, at the networknode, to configure the first terminal as a relay node based on the PIreport; and in response to the determining, directing traffic for thesecond terminal to the first terminal.
 89. The method of claim 88,wherein the secondary coverage configuration information comprises atleast one of secondary coverage signal (SCS) configuration information,SCS resource signal (SCS-R) configuration information, or PI timinginformation.
 90. The method of claim 88, wherein the secondary coverageconfiguration information causes the first terminal to transmit SCS. 91.The method of claim 88, further comprising: transmitting, from thenetwork node to the first terminal, relay node configurationinformation.
 92. The method of claim 91, wherein the relay nodeconfiguration information causes the first terminal to stop transmittingSCS.
 93. The method of claim 88, wherein the PI report indicates thatthe first terminal receives a PI from the second terminal.
 94. Themethod of claim 93, wherein the first terminal is within a networkcoverage, and the second terminal is out of the network coverage.
 95. Adevice, comprising: at least one hardware processor; and anon-transitory computer-readable storage medium coupled to the at leastone hardware processor and storing programming instructions forexecution by the at least one hardware processor, wherein theprogramming instructions, when executed, cause the at least one hardwareprocessor to perform operations comprising: transmitting, from a networknode to a first terminal, secondary coverage configuration information;receiving, at the network node and from the first terminal, a presenceindication (PI) report of a second terminal; determining, at the networknode, to configure the first terminal as a relay node based on the PIreport; and in response to the determining, directing traffic for thesecond terminal to the first terminal.
 96. The device of claim 95,wherein the secondary coverage configuration information comprises atleast one of secondary coverage signal (SCS) configuration information,SCS resource signal (SCS-R) configuration information, or PI timinginformation.
 97. The device of claim 95, wherein the secondary coverageconfiguration information causes the first terminal to transmit SCS. 98.The device of claim 95, wherein the operations further comprise:transmitting, from the network node to the first terminal, relay nodeconfiguration information.
 99. The device of claim 98, wherein the relaynode configuration information causes the first terminal to stoptransmitting SCS.
 100. The device of claim 95, wherein the PI reportindicates that the first terminal receives a PI from a second terminal.101. The device of claim 100, wherein the first terminal has networkcoverage, and the second terminal does not have the network coverage.102. A non-transitory computer-readable medium storing instructionswhich, when executed, cause a computing device to perform operationscomprising: transmitting, from a network node to a first terminal,secondary coverage configuration information; receiving, at the networknode and from the first terminal, a presence indication (PI) report of asecond terminal; determining, at the network node, to configure thefirst terminal as a relay node based on the PI report; and in responseto the determining, directing traffic for the second terminal to thefirst terminal.
 103. The non-transitory computer-readable medium ofclaim 102, wherein the secondary coverage configuration informationcomprises at least one of secondary coverage signal (SCS) configurationinformation, SCS resource signal (SCS-R) configuration information, orPI timing information.
 104. The non-transitory computer-readable mediumof claim 102, wherein the secondary coverage configuration informationcauses the first terminal to transmit SCS.
 105. The non-transitorycomputer-readable medium of claim 102, wherein the operations furthercomprise: transmitting, from the network node to the first terminal,relay node configuration information.
 106. The non-transitorycomputer-readable medium of claim 105, wherein the relay nodeconfiguration information causes the first terminal to stop transmittingSCS.
 107. The non-transitory computer-readable medium of claim 102,wherein the PI report indicates that the first terminal receives a PIfrom a second terminal.